In embedded applications, it is often necessary to store a secret key in non-volatile memory (such as flash memory on an integrated circuit) in products that are widely distributed.
In a system where entities A and B need to communicate with each other (or another entity) in an authenticated manner, they need to share a key. For example, the system can be a printer, A can be a SoPEC printer controller and B can be a Operating Parameter QA Device (e.g. containing the print speed). The system reads the print speed before printing a page.
If B has physical security since it is a QA Device, and A does not have such high security, then it is desirable to store the variant form of the key in A and the base form of the key in B. If the key is extracted from A (having less security than B), then at least other systems cannot be subverted with clone Bs.
However there is the question of injecting the variant key into A. If A can be programmed with a variant key after B has been attached (e.g. A contains non-volatile memory), then this is desirable. If A cannot be programmed after B has been attached (such as is the case with the SoPEC ASIC) then A must be programmed with a random number and after attachment to A, the random number must be transported into B. A can now create a Trusted QA Device and communicate with B using A's variant key.
However if A requires to communicate with additional components such as C and D which are not connected to A or B during initial manufacture, there is a requirement to allow the communication but additionally minimise loss due to key compromise, especially since A is known to be less secure than QA Devices B, C and D. Examples of C and D include a Consumable QA Device such as an ink cartridge, and a Parameter Upgrader QA Device such as a permanent speed-upgrade dongle.
If the base key that is used in B is also used in C and D, then A can communicate securely with C and D. The risk of loss from a key compromise is higher since C and D share the same key.
If A can hold many keys, i.e. can be programmed with many keys during manufacture, then A can be programmed with appropriate variant keys for C and D using the same scheme as described above for B.
However, if the cost of injecting multiple keys into A is high (for example SoPEC has relatively very little non-volatile memory), then an alternative is required that only uses a single key stored in A. There are two approaches to secure communication in this case: communication via key transport, and communication via signature translation.
There are also other cases where it is desirable to enable transport of a key from one entity to at least one other in an authenticated manner.